1. Field of the Invention
The present invention relates to the testing of systems that use smart cards.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
Sun, Sun Microsystems, the Sun logo, Solaris and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
2. Background Art
In modern computing it is desirable for a user to be interacting with a computer, to stop the interacting with the computer, to move to a new computer, and to begin interacting with the new computer at precisely the point where the user stopped interacting with the first computer. To perform such an activity a xe2x80x9csmart cardxe2x80x9d may be used . A smart card is a card-like device that is physically inserted into the computer and read by the computer. The smart card provides information to the new computer that enables it, for example, to locate the data and computer programs necessary to re-create the computing session that was terminated on the old computer.
Typically many computing devices using smart cards are connected to a few servers that store the data and execute the computer programs. When a user inserts the smart card a message is sent to the server informing it that a card has been inserted. Upon receipt of the message the server responds by running a computer program that allows it to communicate with the card to identify what type of card it is and what data and computer programs are associated with the card.
In the past, servers have failed to perform properly when too many end-users were inserting smart cards into their computing devices at the same time. There is currently no effective way to determine what situations might cause a server to perform improperly. Before discussing the drawbacks associated with current schemes, it is instructive to discuss how the nature of computing is changing.
The Nature of Computing
The nature of computing is changing. Originally, computing was xe2x80x9cmachine-centricxe2x80x9d where users accessed a dedicated computer at a single location. The dedicated computer had all the data and computer programs necessary for the user to operate the computer and it ideally had large amounts of hardware, such as disk drives, memory, processors, and the like. With the advent of the Internet, however, different computers have become more desirable and the focus of computing -has become xe2x80x9cservice-orientedxe2x80x9d. In particular, the Internet allows a user to access data and computer programs that exist elsewhere by using a computer network When the user accesses such data or computer programs, the remote computer is said to be providing a service to the user. With the improvement in services available to users, the need to have a dedicated computer following the machine-centric paradigm is greatly reduced.
In particular, computers in a service-oriented environment have little need for robust hardware. For instance, the remote computer processes the instructions before providing the service, so a powerful processor is not needed. Similarly, the service is providing the data so there is little need to have large capacity disk drives. In such an environment, one advantage is that a user can access any computer at any location and still use the computer in the same manner (i.e., have access to the same data and computer programs). For instance, a user may be in location A and running a word processor and a game. In a service-oriented environment, the user could stop using the computer in location A and move to location B where the user could resume word processing and game playing on the different machine at the exact point where the user stopped using the machine at location A An architecture that makes such an interaction possible is described below.
Multi-Tier Application Architecture
In the multi-tier application architecture, a client communicates requests to a server for data, software and services, for example, and the server responds to the requests. The server""s response may entail communication with a database management system for the storage and retrieval of data.
The multi-tier architecture includes at least a database tier that includes a database server, an application tier that includes an application server and application logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests received from the client and forwards data requests to the database server.
FIG. 1 provides an overview of a multi-tier architecture. Client tier 100 typically consists of a computer system that provides a graphic user interface (GUI) generated by a client 110, such as a browser or other user interface application. Conventional browsers include Internet Explorer and Netscape Navigator, among others. Client 110 generates a display from, for example, a specification of GUI elements (e.g., a file containing input, form, and text elements defined using the Hypertext Markup Language (HTML)) and/or from an applet (i.e., a program such as a program written using the Java(trademark) programming language, or other platform independent programming language, that runs when it is loaded by the browser).
Further application functionality is provided by application logic managed by application server 120 in application tier 130. The apportionment of application functionality between client tier 100 and application tier 130 is dependent upon whether a xe2x80x9cthin clientxe2x80x9d or xe2x80x9cthick clientxe2x80x9d topology is desired. In a thin client topology, the client tier (i.e., the end user""s computer) is used primarily to display output and obtain input, while the computing takes place in other tiers. A thick client topology, on the other hand, uses a more conventional general purpose computer having processing, memory, and data storage abilities. Database tier 140 contains the data that is accessed by the application logic in application tier 130. Database server 150 manages the data, its structure and the operations that can be performed on the data and/or its structure.
Application server 120 can include applications such as a corporation""s scheduling, accounting, personnel and payroll applications, for example. Application server 120 manages requests for the applications that are stored therein. Application server 120 can also manage the storage and dissemination of production versions of application logic. Database server 150 manages the database(s) that manage data for applications. Database server 150 responds to requests to access the scheduling, accounting, personnel and payroll applications"" data, for example.
Connection 160 is used to transmit data between client tier 100 and application tier 130, and may also be used to transfer the application logic to client tier 100. The client tier can communicate with the application tier via, for example, a Remote Method Invocator (RMI) application programming interface (API) available from Sun Microsystems(trademark). The RMI API provides the ability to invoke methods, or software modules, that reside on another computer system. Parameters are packaged and unpackaged for transmittal to and from the client tier. Connection 170 between application server 120 and database server 150 represents the transmission of requests for data and the responses to such requests from applications that reside in application server 120.
Elements of the client tier, application tier and database tier (e.g., client 110 application server 120 and database server 150) may execute within a single computer. However, in a typical system, elements of the client tier, application tier and database tier may execute within separate computers interconnected over a network such as a LAN (local area network) or WAN (wide area network).
Thus, with the distribution of functionality between three or more tiers, the machine-centric view of computing diminishes as the need to perform the complete realm of functionality moves away from solely being in the client tier to the other tiers as well. Hence, the type of computing arrangement that is needed on the client tier also changes.
Smart Cards
Since modem computing moves the processing of data and computer programs away from the client, it allows the client the freedom to move between computing devices and continue to have access to the same data and computer programs. Smart cards are one way to tell a computer outside the client tier who the user is, what they were doing before they removed their smart card, and what actions the new computer should take to re-create the computing session.
Problems occur, however, when too many users simultaneously insert smart cards into computing devices. In addition, some users will wiggle their smart cards which causes the server to receive multiple messages instructing it that the smart card has been inserted and removed over and over. In these situations the server becomes overloaded with messages and fails to operate as expected. Thus, it is desirable to know how many simultaneous insertions and removals of smart cards the server can handle so that the operating limits of such a computing arrangement can be verified.
Testing Smart Cards
Traditionally, there are two ways to test the operating limits of this computing arrangement. A first method is to have a person at each computing device manually insert and remove their smart card simultaneously. Then, the behavior of the system can be manually monitored as these actions occur. This method has drawbacks first because it is expensive to have many people present to perform the insertions and removals. Secondly, this method is disadvantageous because since people are manually performing the insertions and removals, there is an upper limit to how fast each step of the process takes place.
A second method of testing the operating limits of a computing arrangement that uses smart cards is to modify both the device which receives the smart card and the software or hardware in the computing system that enables the use of the smart card. This modification includes the addition of additional instructions to the computer that simulate smart card insertions and removals. This method is disadvantageous because modifications to the system are required. This introduces behavior that might not normally occur in an un-modified system
The present invention is for non-invasive testing of smart cards. The invention comprises a central controller unit connected to a host computer. The controller unit is connected to one or more computing devices via a switch. In one embodiment, the switch is a cross-point matrix switch where many computing devices are coupled to the controller unit via the switch. The controller unit communicates with the host computer and accepts commands from the host computer so that the host computer can configure the controller unit to perform a testing scenario. One testing scenario tests the operating limit of a server where smart cards are simultaneously being inserted and removed from multiple testing devices connected to the server.
The switch connects to one or more testing devices, which includes one or more probes and one or more card terminals. The probes are devices, for instance boards, that plug into card terminals. Each probe has a motor that is coupled to a cylindrical tube. The motor-tube configuration is used to actuate a card detect sensor in the unit that receives the inserted smart card (card terminal). In operation, the motor-tube configuration is used to simulate repeated insertions and removals of smart cards without the physical removal of the probe that is simulating the smart card.
In one embodiment, the testing device includes a card terminal used for programming smart cards. In another embodiment, the testing device includes one or more smart card sockets. Each computing device may connect, via the switch, to any of the units configured to receive the smart cards, including the card terminal used for programming smart cards. Using the switch, the controller can cause one of the computing devices (or none) to be connected to one of the smart card terminals under test, and by using the motor and actuating the tube on the board, a card insertion and removal is simulated.
The host computer interfaced to the controller is used to generate and download commands to the controller and to receive status reports from the controller and the systems under test to verify the success of each test.